XML is a versatile markup language, capable of labeling the information content of diverse data sources including structured and semi-structured documents, relational databases, and object repositories. A query language that uses the structure of XML intelligently can express queries across all these kinds of data, whether physically stored in XML or viewed as XML via middleware. As increasing amounts of information are stored, exchanged, and presented using XML, the ability to intelligently query XML data sources becomes increasingly important. One of the great strengths of XML is its flexibility in representing many different kinds of information from diverse sources. To exploit this flexibility, an XML query language must provide features for retrieving and interpreting information from these diverse sources.
The XQuery Query Language
The XQuery language is described in “XQuery 1.0: An XML Query Language, W3C Working Draft 4 Apr. 2005” available from the W3C organization; the entire contents of which are incorporated by this reference for all purposes as if fully disclosed herein. XQuery is designed to be a language in which queries are concise and easily understood. XQuery is also flexible enough to query a broad spectrum of XML information sources, including both databases and documents. XQuery operates on the abstract, logical structure (i.e., the data model) of an XML document, rather than its surface syntax. Note that an XQuery expression comprises one or more expressions (i.e., sub-expressions).
The XSLT Transformation Language
The XSLT language is described in “XSL Transformations (XSLT) Version 1.0, W3C Recommendation 16 Nov. 1999” available from the W3C organization; the entire contents of which are incorporated by this reference for all purposes as if fully disclosed herein. XSLT is a language for transforming XML documents into other XML documents or other markup language documents (e.g., HTML). XSLT is designed for use as part of XSL, which is a stylesheet language for XML. In addition to XSLT, XSL includes an XML vocabulary for specifying formatting. XSL specifies the styling of an XML document by using XSLT to describe how the document is transformed into another document that uses the formatting vocabulary. XSLT is also designed for use independently of XSL.
A transformation in the XSLT language is expressed as a well-formed XML document. A transformation expressed in XSLT describes rules for transforming a source tree into a result tree. The transformation is achieved by associating patterns with templates. A pattern is matched against nodes in the source tree. A template is instantiated to create part of the result tree. The result tree is separate from the source tree and the structure of the result tree can be completely different from the structure of the source tree. In constructing the result tree, nodes from the source tree can be filtered and reordered, and arbitrary structure can be added.
A transformation expressed in XSLT is called a stylesheet because, in the case when XSLT is transforming into the XSL formatting vocabulary, the transformation functions as a stylesheet. A stylesheet contains a set of template rules. A template rule has two parts: (1) a pattern which is matched against nodes in the source tree, and (2) a template which can be instantiated to form part of the result tree. This allows a stylesheet to be applicable to a wide class of documents that have similar source tree structures.
A template is instantiated for a particular source node to create part of the result tree. A template can contain elements that specify literal result element structure. A template can also contain elements from the XSLT namespace that are instructions for creating result tree fragments. When a template is instantiated, each instruction is executed and replaced by the result tree fragment that it creates. Instructions can select and process descendant source nodes. Processing a descendant node creates a result tree fragment by finding the applicable template rule and instantiating its template. Note that nodes are only processed when they have been selected by the execution of an instruction. The result tree is constructed by finding the template rule for the root node and instantiating its template.
XSLT and XQuery share the same XPath as a common core. Additionally, both languages have constructs to construct new nodes in an XML result tree, provide constructs for iterations, conditional testing, allow read-only variables usage (functional language without assignment semantics), support user defined functions, etc. A significant difference between the two languages is that XSLT has the powerful template rule matching driven style of execution, which XQuery does not have. In this sense, XSLT is even more declarative than XQuery as it does not require programmers to state procedurally how each template is applied.
However, the declarative nature of XSLT stylesheets is at the expense of performing what is often a complex template matching routine. This runtime matching routine is required because of the lack of advance knowledge about the input content and, therefore, which particular templates are most appropriate and should be invoked to transform the input content. Furthermore, sequential languages such as XQuery are more computationally efficient than template-matching driven languages such as XSLT because a processor executing a sequence of instructions in the sequential language simply knows what to do, without having to perform rule-based matching to determine what to do.
One approach to transforming XML data based on an XSLT stylesheet, in the context of a relational database system, is referred to as functional evaluation. FIG. 1 is a block diagram that illustrates a functional evaluation process flow for an XSLT transformation request. Functional evaluation of an XSLT transformation request 102, in view of the XML input data and the particular XSLT stylesheet specified in the request 102 (e.g., an xmltransform( ) operator), generally involves the following: (a) constructing a structured XML document 106 from the XML data storage layer (e.g., if the XML data is shredded and stored in relational and/or object-relational tables of a relational database management system (RDBMS), then the actual construction of the XML document from relational or object-relational tables is required); (b) materializing the XML document into a DOM-like (document object model) structure, which is a tree-like structure used to represent the structure of the data; (c) calling into an XSLT engine 108 to apply the XSLT stylesheet 107 and its associated set of transformation templates to the input DOM, which includes performing the template matching routine; (d) generating a new DOM that represents the transformed XML data; and (e) re-mapping the transformed data into new layouts or table structures (i.e., table translation), via a DOM interface 109 and RDBMS engine 104. This conceptual functional evaluation of XMLTransform( ) with XSLT style sheet is expensive because XML data needs to be constructed from various pieces from different storage tables and then passed to a standalone XSLT engine. Based on the foregoing, there is a need for a better process for transforming, via XSLT stylesheets, XML data stored in a relational database system.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.